# Конструирование методологии
## Описание
Для организации разработки применяются различные методологии, по сути каждая методология – это набор правил, ритуалов и артефактов, помогающих команде двигаться в заданном направлении. В компаниях редко встречаются методологии в «книжном» варианте. Часто за основу берётся какая-то общеизвестная, а потом подпиливается под себя. Также встречаются варианты, когда даже в одном отделе в зависимости от критичности или специфики работы методологии могут отличаться. Есть методологии, которые оставляют довольно много пространства для улучшения, но для работы с ними требуется уметь их конструировать. Есть те, что жёстко описывают как должно быть и этого пространства не оставляют.

## Почему ветка важна?
Для тимлида:
- Появляется возможность доработать методологию под свою команду.
- Во всех методологиях есть «слепые зоны», про которые они ничего не говорят. Хорошо, когда тимлид может продумать их самостоятельно.
- Умение гибко подбирать и модифицировать методологию при появлении новых ответственностей команды.
- Тимлид может выбирать методологию исходя из ценностей и картины мира команды.

Для команды:
- Некоторые строгие методологии подразумевают изменение команды и людей под них. Тимлид может интегрировать её с минимальными потерями или доработать её так, чтобы люди не страдали.
- Если методология подпиливается под команду, то можно добиться того, чтобы остались только понятные для команды практики.

## Что будет, если её не делать?
Можно не уметь собирать методологию с нуля, но тогда необходимо хорошо разбираться в одной или нескольких существующих.

Ниже рассмотрены кейсы, в которых тимлид умеет в лучшем случае в одну из общеизвестных:
- У лида нет возможности что-то значительно поменять в методологии.
  - Будет получаться, что команда подстраивается под методологию.
- Нет сформулированной методологии. Люди просто делают работу.
  - Это приводит к хаосу в случае отклонения от обычного сценария. Например, приходит лид соседней команды и просит сделать какую-то задачу. Участники и лид не понимают, как надо в такой ситуации действовать.

## На кого может быть делегирована?
- Scrum-мастер
- Project-менеджер
- Тимлид ниже уровнем

## Примеры поведения
### Примеры плохого поведения
- Изменение методологии опускается сверху. Например, включается режим «Scrum в каждый дом».
- Разница между ценностями команды и ценностями, которые постулируются в внедряемой методологии, сильно отличаются.
- Методологии меняются очень часто. Это плохо из-за того, что каждый переезд длителен по времени.
- Методология работает по принципу карго-культа. Никто не понимает зачем нужны те или иные «ритуалы».

### Примеры хорошего поведения
- Тимлид понимает, как работают разные методологии, может комбинировать практики из разных.
- Методология развивается исходя из потребностей команды.

## Способы прокачки
### Практика
Ветка появилась под впечатлением от выступления Филиппа Дельгядо, потому ниже будет приведена краткая выжимка.

#### Подготовка
##### Расписываем User Story
Пример:
```
User Story:
Как разработчик я хочу найти свою следующую задачу и приступить к её реализации.

Acceptance Criteria:
Как разработчик я могу посмотреть все мои актуальные задачи
Как разработчик я могу оценить срочность/приоритет задач

Exceptions:
Если задач нет, то разработчик знает, кого спросить

Links:
Сценарии подготовки краткосрочного плана
```
Это позволяет заранее сформулировать ожидания от методологии, которая должна получиться, заложив особенности работы команды и компании.
Далее заменяем роли на реальных людей в команде. Это позволяет лучше увидеть узкие места.
Убираем лишние артефакты, коммуникации. Чем более простая методология, которая работает, тем более она идеальная.

##### Выбираем инструменты
Инструменты – то, что помогает оптимизировать работу и сделать её максимально комфортной. Можно мысленно разделить их на следующие группы:
- Коммуникации: мессенджеры, инструменты для проведения код-ревью
- Хранение информации и визуализация: доски задач, борды для проектирования, графики сгорания задач, база знаний
- Разработки: IDE, инструменты работы с VCS, CI/CD, линтеры

Важно выбрать удобные инструменты, иначе ими не будут пользоваться. Удобство инструмента надо проверять самостоятельно.

##### Активно обсуждаем
Обсуждение позволяет доработать методологию если что-то или кого-то забыли.
Это помогает убедиться, что мы никого не обидели. Важно, чтобы все понимали и были согласны с полученными ролями. Обиженный человек будет саботировать.

#### Внедрение
##### Уважение коллег
- Бережём чужое время. Максимально автоматизируем всю рутину. Это позволяет команде экономить силы на важные задачи.
- Помогаем при переходе. Подсказываем, если что-то непонятно.
- Описываем конкретные действия. Документация помогает фиксировать методологию и договорённости.

##### Внедряем постепенно
- Не все практики сразу. Это позволяет проводить методологии плавно и по возможности безболезненно для команды.
- Тропинки протаптываются сами. Не нужен жёсткий workflow. Это позволяет появиться практикам, которые позже превратятся в правила.
- KISS. Чем проще, тем лучше.

#### Поддерживаем
- Заранее закладываем время своё и команды на поддержку. Процессы не бывают бесплатными.
- Сразу исправляем ошибки.

## Консультации
- [Telegram-чат TL Bootcamp](https://tlinks.run/tlbootcamp)

## Теория
### Видео
- [Методология как конструктор: инструкция по сборке / Филипп Дельгядо](https://www.youtube.com/watch?v=Jt2C4ta1rEo)
